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H I Integrating a Local Database into the StarView Distributed User Interface 
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We are developing a distributed user interface to the Space Telescope Data Archive and 
Distribution Service (DADS) known as StarView. The DADS architecture consists of the 
data archive as well as a relational database catalog describing the archive. StarView is a 
client/server system in which the user interface is the front-end client to the DADS catalog 
and archive servers. Users query the DADS catalog from the StarView interface. Query 
commands are transmitted via a network and evaluated by the database. The results are 
returned via the network and are displayed on StarView forms. Based on the results, users 
decide which data sets to retrieve from the DADS archive. Archive requests are packaged 
by StarView and sent to DADS, which returns the requested data sets to the users. 

The advantages of distributed client/server user interfaces over traditional one-machine sys- 
tems are well known. Since users run software on machines separate from the database, 
the overall client response time is much faster. Also, since the server is free to process only 
database requests, the database response time is much faster. Disadvantages inherent in 
this architecture are slow overall database access time due to the network delays, lack of 
a “get previous row” command, and that refinements of a previously issued query must be 
submitted to the database server, even though the domain of values have already been re- 
turned by the previous query. This architecture also does not allow users to cross correlate 
DADS catalog data with other catalogs. Clearly, a distributed user interface would be more 
powerful if it overcame these disadvantages. 

We are integrating a local database into StarView to overcome these disadvantages. When 
a query is made through a StarView form, which is often composed of fields from multiple 
tables, it is translated to an SQL query and issued to the DADS catalog. At the same time, 
a local database table is created to contain the resulting rows of the query. The returned 
rows are displayed on the form as well as inserted into the local database table. Identical 
results are produced by reissuing the query to either the DADS catalog or to the local table. 

Relational databases do not provide a “get previous row” function because of the inherent 
complexity of retrieving previous rows of multiple-table joins. However, since this function 
is easily implemented on a single table, StarView uses the local table to retrieve the previous 
row. Also, StarView issues subsequent query refinements to the local table instead of the 
DADS catalog, eliminating the network transmission overhead. Finally, other catalogs can 
be imported into the local database for cross correlation with local tables. Overall, we believe 
that this is a more powerful architecture for distributed, database user interfaces. 
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